Skip to content

feat: AMD SEV-SNP app key provisioning (GetAppKeyAmd)#630

Open
DeDTihoN wants to merge 8 commits intoDstack-TEE:masterfrom
scrtlabs:feat/amd-sev-snp
Open

feat: AMD SEV-SNP app key provisioning (GetAppKeyAmd)#630
DeDTihoN wants to merge 8 commits intoDstack-TEE:masterfrom
scrtlabs:feat/amd-sev-snp

Conversation

@DeDTihoN
Copy link
Copy Markdown

@DeDTihoN DeDTihoN commented Apr 2, 2026

feat: AMD SEV-SNP app key provisioning (GetAppKeyAmd)

Adds AMD SEV-SNP support to the KMS. AMD-based confidential VMs can now obtain the same application keys (disk encryption, env secrets, k256 identity) as Intel TDX VMs.

How it differs from GetAppKey (TDX)

TDX (GetAppKey) AMD SEV-SNP (GetAppKeyAmd)
Attestation transport RA-TLS mTLS client cert SNP report + VCEK cert chain in request body
Root of trust Intel PCK Root CA via DCAP/PCCS AMD Root Key (ARK) — hardcoded, no PCCS needed
Measurement RTMRs extended at runtime, verified by replaying event log Single MEASUREMENT fixed at launch: OVMF + kernel + initrd + cmdline
compose/rootfs binding Extended into RTMR3 at runtime via event log Embedded in kernel cmdline at launch → part of MEASUREMENT; KMS recomputes expected value and rejects any mismatch
Auth webhook os_image_hash + compose_hash os_image_hash + compose_hash
Response delivery Plaintext over TLS — session is bound to the attested mTLS identity ECDH-encrypted to VM's X25519 pubkey from report_data

AMD SEV-SNP supports generating on-demand attestation reports with custom report_data (via /dev/sev-guest), so RA-TLS over mTLS would be technically feasible. However, implementing it would require changes at multiple levels: AMD-specific X.509 extension format, a new code path in handle_prpc_impl to parse two different attestation types from client certs, and a new cert generation flow parallel to the existing TDX one. Instead, the current approach sends the SNP report in the request body and ECDH-encrypts the response to the VM's X25519 pubkey embedded in report_data[0..32]. The VM places its pubkey there before requesting the report from the kernel, so AMD hardware attests it. This is simpler to implement and equivalent in security.

Changes

kms/src/main_service.rs

  • New get_app_key_amd: verifies AMD cert chain (ARK → ASK → VCEK → SNP report), recomputes expected MEASUREMENT, calls auth webhook, derives keys, ECDH-encrypts response

kms/rpc/proto/kms_rpc.proto

  • New GetAppKeyAmd RPC, GetAppKeyAmdRequest, AppKeyAmdResponse

kms/src/config.rs, kms/kms.toml

  • New optional [core.sev_snp] section (ovmf_path, guest_features); if absent, measurement recomputation is skipped

dstack-attest/

  • New DstackSevSnp attestation mode variant

@kvinwang
Copy link
Copy Markdown
Collaborator

kvinwang commented Apr 3, 2026

Thanks for the PR.

I still need to review the details, but one high‑level concern: it’s not clear how this integrates with the existing dstack-os images, and for SEV-SNP the way we build the OS image and launch the CVM is part of the security model.

Could you provide the scripts of how the SEV-SNP OS image is built and the CVM is launched? Also, in what environment do you expect this CVM to run (e.g. GCP, bare metal)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants